In video-on-demand systems, programs are typically transported from central repositories to subscriber locations as bit streams using communications networks. The bits of the bit streams are usually communicated over the networks in a contiguous maimer, and at a constant rate which is synchronized to a network clock.
The programs, which may include video and audio components, can represent games, movies, sporting events, and so forth. To reduce the bandwidth required to transport the bit streams, the source programs are usually encoded and compressed according to some industry standard, for example the Moving Pictures Experts Group (MPEG) standard, see "Generic Coding of Moving Pictures and Associated Audio," ISO/IEC 13818-1, June 1994. To conserve time and resources, the programs, if possible, are usually stored in the encoded form, so that they may be available on-demand. The encoded bit streams can deliver programs having a quality suitable for entertainment at rates in the range of one to six Megabits per second (Mb/s). At the subscriber locations, the bit streams are decoded and decompressed to reconstruct the programs.
In order to avoid distortion of a program, the bandwidth of the encoded bit stream is carefully matched to the bandwidth of the network that will be used to transport the bit stream. This makes sense. If the bit stream were to be delivered at a rate which is different than the encoded rate, the program would be distorted in color, sound, and motion. Furthermore, if the program were delivered at a much higher rate, storage buffers at the subscriber locations, used during decoding of the bit stream, would quickly overflow, resulting in a total loss of the program.
Traditionally, a process known as "padding" has been used to equalize the rate at which the bit stream is encoded with the rate at which the network will transport the bit stream. Padding adds extra "null" bits into the bit stream for portions of the program which would otherwise use less than the network bandwidth. For example, if a one second portion of a program, perhaps a static and silent image, is encoded into a bit stream which only takes 0.8 seconds to transport, the bit stream is padded with 0.2 seconds of meaningless null bits. Thus, the program is delivered at the correct rate.
There are several problems with padding bit streams. In order to add exactly the right number of bits to the bit stream, the encoding process must know the bit rate of the network that will be used to transport the bit stream. However, all synchronous communications networks do not necessarily transport bits at the same rate. In fact, in many instances, the rate at which the network will operate is not known until a communications circuit is established between the program repository and the subscriber location. Therefore, the program must be encoded every time it is delivered, or multiple copies of the encoded bit stream must be maintained, one copy for each possible network bit rate. Also, as the bandwidth of the public networks are upgraded to communicate at higher bit rates, previously encoded programs will need to be re-encoded.
Furthermore, padding consumes time and resources. The pad bits have to be added while encoding, and removed while decoding. Irrelevant pad bits occupy storage media, and require transport bandwidth. Additionally, it may not always be possible to exactly match the bandwidth of the padded bit stream with the bandwidth of the network since synchronous networks usually transport bit streams in units of fixed size packets or cells, for example, packets or cells having 188 or 53 octets (bytes) of bits. Therefore, the resolution of the padding is limited by the size of the transport units.
Therefore, it is desired to provide a system and method for transporting bit streams having variable bandwidth requirements over a synchronous communications network.